ゲームデータのPreloadabilityを考える

概要

特にUnityに限る話ではなく、どんなエンジンで作ろうが言えそうな内容。

こんな仕組み作って使ってみたよ、っていうのを基礎として、俺の考えた最高のPreloadabilityの話をする。

・Client側のプラットフォームがゲームをDLしようと試みる

・データをDLする

・実際に遊べるようになる

っていう動作の間に、ユーザーが実際にその素材を必要とする前に、どこまで何をDLさせるか、っていうのを効率良く制御することを考える。

前提

ある程度は運用スタイルを含んだお話になる。

通信方法については特に指定しない限りはHTTP1系を使う。

また、章の中では動作するサンプルコードを元に話をしていくが、このサンプルコード、特にエラーハンドリングとかは考えてないので、

実際に使ってみてどんな目に合うかは君次第だ！！

Preloadのモチベーション

次のようなモチベーションを掲げておく。

1.最速で遊んでほしい

ユーザーがゲームをDLしてから、すべての素材をDLしてからゲーム開始、、ってやると、無限の時間がかかってしまう。

ムービー流したりいろいろ、、ユーザーの我慢を促進することは出来るっちゃあ出来るんだけど、

「そもそもそのリソースを俺が目にすることがあるのだろうか？」っていう素材を、遊ぶ前にDLさせるのはこう、、なんていうか、、辛いよなっていう。

あとムービーは飛ばすしストーリーはスキップするよな、設定なんかよりカタルシスとかそういうのが欲しいわけだよ(暴言)

2.ユーザーが端末内に持ってる素材をできるだけ少なくしたい

ユーザーの端末内に大量の素材を置いておくことになる、、ので、まずそれをできるだけ小さくしたいよな～っていうのはよくある欲求だとおもう。

3.リリース後はサーバー側からコントロールしたい

ゲームが一度世に出ると、そのあとユーザーの端末と管理側を繋ぐのは通信APIとかだけになる。

ユーザーが保持している素材について、サーバー側が何かできるといいなっていう感じ。

ユーザーが手元で動かすゲーム自体をUpdateする、という方法もある。

個人製作のゲームの場合は主にサーバーを持たないようにしたいな～ってなると思うが、

この章では、「もし機構を最小化できたらどんな感じか」というのを念頭に、そのメリットを書いてみようと思う。

まあ課金機構とかいれようものなら、どこかにサーバ置いて、、ってなっちゃうんだけどさ。

課金に関してはまあ、、AppleとかGoogleにお任せ機構が選べるならそれも良し。

これらが叶えば、ユーザーは常に必要最低限の通信をして、ゲームのプレイができそうだ。

願望が整ったところで、その願望をどのように叶えればいいのか、を書いていく。

っていう記事をUnibook4向けに書いてます。